1. Field of the Invention.
This invention relates in general to network management, and more particularly to a method and apparatus for improving dynamic simple network management protocol GetNext processing.
2. Description of Related Art.
Data communication is the foundation upon which the information economy rests. Almost every device we use today is a computer-based system including our phones, cars, personal digital assistants, printers, desktop and portable computers, microwaves, etc. Moreover, the networking of such devices is becoming a reality in the hope that our lives will become more convenient and our leisure time will increase. For example, world-wide networks gather data about such diverse subjects as current events, the stock market, the temperature of our homes, etc. These networks evolved as independent entities without the ability, or, until recently, the need, to interconnect with one another. New technologies, generically named xe2x80x9cinternetworkingxe2x80x9d, have emerged making it possible to interconnect many disparate physical networks and make them function as a coordinated unit. Thus, using internetworking technologies, a host, for example, on one network, may traverse multiple networks and communicate with another host on a different network.
In the early days of networking, as the interconnecting of networks grew, the monitoring and maintenance of these networks became more difficult. It soon became evident that a network management protocol needed to be developed. The first protocol used was the Simple Network Management Protocol (SNMP). SNMP was commonly considered to be a quickly designed interim solution to internetwork management difficulties while other, larger and better protocols were being designed. Out of these protocol designs of the 1980""s emerged SNMPv2, which incorporated many of the features of the original SNMP (which is still in wide use today) as well as a few added features that addressed the original protocol""s shortcomings. Today, SNMP based network management systems are widely used to locate and correct problems in a network.
SNMP normally operates by having one or more central manager node(s) oversee multiple agent nodes as shown in FIG. 1. As depicted, each agent node 120 supports a local, tree-structured database, called a Managed Information Base 130 (MIB) and software that allows a valid manager node 110, such as a host computer, to access information in MIB 130. Agent node 120, which may reside in any agent device such as routers, database managers, printers, etc., responds to command messages sent by manager node 110.
SNMP describes the packet layout (or protocol data unit) for messages between management agents and managing processes. The first version of SNMP, included only five possible messages. Manager Messages 140 are messages that can be sent by manager node 110 to agent node 120 and include xe2x80x9cGetxe2x80x9d, xe2x80x9cGetNextxe2x80x9d and xe2x80x9cSet.xe2x80x9d xe2x80x9cGetxe2x80x9d is a message that is sent to read certain locations in MIB 130. The GetNext-Request message provides an efficient method for the managing process to search tables of values. xe2x80x9cSetxe2x80x9d enables the manager to update variables.
Agent Messages 150 that may be sent by agent node 120 to manager node 110 include: xe2x80x9cGetResponsexe2x80x9d and xe2x80x9cTrap.xe2x80x9d xe2x80x9cGetResponsexe2x80x9d is sent in response to a Get, GetNext, or Set command, and returns information to manager 110. The GetRequest message with one or more object instances asks for the values of those object instances. xe2x80x9cTrapxe2x80x9d is sent asynchronously or, in other words, upon the occurrence of a predetermined event. Certain traps are predefined by SNMP. Other Traps are xe2x80x9centerprise specificxe2x80x9d which means they can be defined to carry information specific to a particular algorithm or service.
SNMP management has two other components in addition to the SNMP messages: the Structure of Management Information (SMI) and the MIB. The SMI is a toolkit for creating a management information base, or MIB. The SMI identifies the permissible data types and spells out the rules for naming and identifying MIB components. It defines the structure of the SNMP naming mechanism. The MIB is a layout or schema for information relevant to managing networks and their component devices. SNMP is most often implemented over IP. However, nothing in the standard prevents SNMP messages from being delivered with TCP, HTTP, or non-Internet protocols, such as IPX or AppleTalk""s datagram delivery protocol.
The SMI specifies the allowable data types in the MIB, and it spells out the ways data can be represented. Also, it defines a hierarchical naming structure that ensures unique, unambiguous names for managed objects, which are the components of a MIB. Compared with the objects that general purpose programmers use to build applications, SNMP-managed objects are very simple and stripped-down. MIB objects typically have six or so attributes. For instance, an object usually has a name, such as iflnErrors or tcpAttemptFails; an object identifier in dotted decimal form, such as 1.3.6.1.2.1.2.2.1.14; a syntax field, which selects one of several possible data types such as Integer, IPAddress, or Counter; an access field, which selects among xe2x80x9cnot-accessible,xe2x80x9d xe2x80x9cread-only,xe2x80x9d xe2x80x9cread-write,xe2x80x9d and xe2x80x9cwrite-onlyxe2x80x9d; a status field consisting of either xe2x80x9cmandatory,xe2x80x9d xe2x80x9coptional,xe2x80x9d xe2x80x9cdeprecated,xe2x80x9d or xe2x80x9cobsoletexe2x80x9d; and a text description of the object.
MIB objects are static; they""re compiled from a text-like description language to a binary form that agents and managing processes can load. MIB-II is the current generic TCP/IP MIB standard, and specific MIBs have been adopted for bridges, printers, and other entities to provide a useful common denominator for management application developers. However, most vendors find it necessary to define their own proprietary objects to take advantage of the capabilities of their own products.
The SMI is two layers of abstraction away from the sort of management data that IT staff and users care about. SMI sets the rules for defining MIB objects, which are one layer of abstraction away from management data. All these abstract rules and reserved words make it possible to have machine-readable specifications that remain comprehensible to humans. The SMI enables a vendor to write an SMI-compliant management object definition, run the text through a standard MIB compiler to create executable code, and install the code in existing agents and in management consoles that could then begin generating reports and charts about such occurrences.
The MIB is a hierarchical name space, with the registration of its nodes administered by the Internet Assigned Numbers Authority (IANA). FIG. 2 illustrates the hierarchical name space for the Management Information Base (MIB) structure. In FIG. 2, the object ID for every relevant MIB object begins with the ISO 1 object identifier 210, National and International Organizations 3 object identifier 212, the Department of Defense 6 object identifier 214, and the Internet Architecture Board 1 object identifier 216. Thus, according to the hierarchy as illustrated in FIG. 2, the object ID for every relevant MIB object must begin with either 1.3.6.1.2.1 (which represents the mib-2 node 220) or 1.3.6.1.4.1 (the enterprises node 230). The term MIB is also used to refer to specific collections of objects used for particular purposes. Thus, MIB objects under the mib-2 node 220 include the RMON (remote monitoring) MIB objects and other generic MIB objects 250, while those under the enterprises node include all proprietary MIB objects 260. It has been estimated that there are at least 10 times as many proprietary MIB objects as there are generic ones.
Each MIB object has a value associated with it according to the syntax part of its specification-for example, the number of packets that have come in since the last system reset, the number of clock ticks since the last reset, or the administrative state of a router. When a MIB object is instantiated on a device or other entity, the value associated with the object is sometimes called a MIB variable. SNMP agents store MIB variables and send them to SNMP managing processes (or consoles) when they are asked to. The value of a MIB variable is the basic unit of useful management information.
MlBs are often divided into groups of related objects. MIB-2 has 10 groups, including xe2x80x9csystem,xe2x80x9d xe2x80x9cinterfaces,xe2x80x9d xe2x80x9cIP,xe2x80x9d xe2x80x9cTCP,xe2x80x9d xe2x80x9cUDP,xe2x80x9d and xe2x80x9cSNMPxe2x80x9d. The RMON MIB for Ethernet segments has nine groups, including xe2x80x9cstatistics,xe2x80x9d xe2x80x9chistory,xe2x80x9d xe2x80x9calarm,xe2x80x9d xe2x80x9cevent,xe2x80x9d and xe2x80x9ccapturexe2x80x9d.
SNMP managed entities-hubs, routers, database managers, printers, etc.xe2x80x94must be outfitted with an agent that implements all the MIB objects relevant to them. The managing process must also be aware in advance of all the MIB objects implemented on entities it is expected to manage. Management consoles, such as HP OpenView, that communicate with many kinds of devices must allocate incremental resources for each different type of entity-it""s no wonder these platforms are resource intensive.
SNMPv2 has been enhanced to include security, improved support for systems and applications management, as well as other extensions. SNMPv2 also enables manager-to-manager communication, and therefore, provides a more distributed management model and makes retrieving tabular data more efficient with a new message type.
For a device that supports SNMP, and supports dynamic information in SNMP, such as a printer supporting a job MIB, the information in the table is very dynamic, as jobs come and go. It is expensive for the SNMP agent in the device to perform conventional GetNext processing on the dynamic information by figuring out which row is xe2x80x9cnextxe2x80x9d after a given row if it is not practical to maintain such information accurately at all times. Thus, the device must look through all possible rows to find the xe2x80x9cnextxe2x80x9d row.
In such a device, the SNMP performance will be poor because the tables are normally accessed by an SNMP client by performing GetNexts through the table, on each column of the table. For a table with n rows and m columns, then, the entire list of possible rows must be gone through (n)xc3x97(m) times, simply to support one client getting all the information once. For example, for 50 rows and 10 columns, all 50 rows would be gone through 50xc3x9710 times, for a total of 50xc3x9750xc3x9710=25,000 accesses of row index information, for one single client to retrieve the table information once! Now imagine 10 clients, each of which is going to access the table every 10 seconds.
It can be seen that there is a need for a method and apparatus for improving dynamic simple network management protocol GetNext processing.
To overcome the limitations in the prior art described above, and to overcome other limitations that will become apparent upon reading and understanding the present specification, the present invention discloses a method and apparatus for improving dynamic simple network management protocol GetNext processing.
The present invention solves the above-described problems by building the xe2x80x9cGetNextxe2x80x9d list once, then caching that list for a given amount of time.
A method in accordance with the principles of the present invention includes building a GetNext list, storing the GetNext list, maintaining the stored GetNext list for a predetermined amount of time and using the stored GetNext list to determine the next row for a subsequent GetNext request from a first client when the time has not expired.
Other embodiments of a method in accordance with the principles of the invention may include alternative or optional additional aspects. One such aspect of the present invention is that the method further includes refreshing the GetNext list when the time has expired.
Another aspect of the present invention is that stored GetNext list is accessed by a second user client.
Another aspect of the present invention is that the storing includes caching the list in dynamic memory.
Another aspect of the present invention is that the stored GetNext list is implemented as an array.
Another aspect of the present invention is that storing the GetNext list includes storing only row index information.
Another aspect of the present invention is that the method further includes denying return of data for rows that are deleted after the GetNext list is stored.
Another aspect of the present invention is that the method further includes returning an OID reporting a current number of rows in the GetNext list, saving the OID and returning the OID on every access thereafter rather than recomputing the number of rows on each access.
Another aspect of the present invention is that the method further includes returning an OID reporting for each row a number of rows prior thereto.
In another embodiment of the invention, a system controller for managing a device is provided. The system controller includes a dynamic management information base defining objects associated with the device for managing the device, a management agent and device controller for managing operation of the device as defined by the objects with the management information base and a management information base manager, interfacing with the dynamic management information base and the management agent and device controller, for building a GetNext list, storing the GetNext list, maintaining the stored GetNext list for a predetermined amount of time and using the stored GetNext list to determine the next row for a subsequent GetNext request from a first client when the time has not expired.
In another embodiment of the invention, a network system is provided. The network system includes a plurality of network nodes and a network device, wherein the network device includes a system controller for managing a device, the system controller further includes a dynamic management information base defining objects associated with the device for managing the device, a management agent and device controller for managing operation of the device as defined by the objects with the management information base and a management information base manager, interfacing with the dynamic management information base and the management agent and device controller, for building a GetNext list, storing the GetNext list, maintaining the stored GetNext list for a predetermined amount of time and using the stored GetNext list to determine the next row for a subsequent GetNext request from a first client when the time has not expired.
In another embodiment of the invention, a printer is provided. The printer includes a channel for receiving a data stream from a physical connection running a transport protocol stack, an interpreter, coupled to the channel, for converting a description of intended print instances in the data stream into images that are to be marked on print media, an input, output and a marker, the input providing the media to a marker for producing marks on the print media according to the images, the marker providing the printed media to the output and a system controller for implementing control functions for processing the images from the interpreter to the marker, the system controller further includes a dynamic management information base defining objects associated with the printer for managing the device, a management agent and printer controller for managing operation of the printer as defined by the objects with the management information base and a management information base manager, interfacing with the dynamic management information base and the management agent and printer controller, for building a GetNext list, storing the GetNext list, maintaining the stored GetNext list for a predetermined amount of time and using the stored GetNext list to determine the next row for a subsequent GetNext request from a first client when the time has not expired.
In another embodiment of the invention, an article of manufacture including a program storage medium readable by a computer, the medium tangibly embodying one or more programs of instructions executable by the computer to perform a method for improving dynamic simple network management protocol GetNext processing is provided, wherein the method includes building a GetNext list, storing the GetNext list, maintaining the stored GetNext list for a predetermined amount of time and using the stored GetNext list to determine the next row for a subsequent GetNext request from a first client when the time has not expired.
These and various other advantages and features of novelty which characterize the invention are pointed out with particularity in the claims annexed hereto and form a part hereof. However, for a better understanding of the invention, its advantages, and the objects obtained by its use, reference should be made to the drawings which form a further part hereof, and to accompanying descriptive matter, in which there are illustrated and described specific examples of an apparatus in accordance with the invention.